Dynomotion

Group: DynoMotion Message: 12448 From: Sam Marrocco Date: 10/27/2015
Subject: Feature wish for Interpreter in dotnet
It would be very useful to see the addition of an overloaded method(s)
added to Interpreter.Interpret(file) method, including:

Interpreter.Interpret(GCodeLines as collection)
Interpreter.Interpret(GCodeLines as array)

...where GCodeLines is a collection or array of single strings
consisting of lines of gcode.

This would avoid the thrashing disk accesses and pauses that happen
where lots of single gcode commands are sent one file at a time to the
interpreter.

Please and thank you!


sam marrocco | chief technical officer
ringside.cutters.flavor.picnic.moonlink

248 548 2500 w
248 910 3344 c

ringsidecreative.com

<http://ringsidecreative.com/>
Group: DynoMotion Message: 12450 From: TK Date: 10/27/2015
Subject: Re: Feature wish for Interpreter in dotnet
Hi Sam,

I think this would be a very difficult thing to add because of all the (unfortunate) dependencies on operating on a file.  Such as subroutine calls and returns, error line number reporting, rewinding on Halt, status callbacks, executing up to a certain line number or number of lines, etc. 

Why not write the the lines of GCode to a file?  I don't think the disk thrashing of the file is a significant issue when you consider everything else that occurs when invoking the Interpreter.

Regards
TK


On 10/27/2015 6:24 PM, Sam Marrocco SMarrocco@... [DynoMotion] wrote:
 

It would be very useful to see the addition of an overloaded method(s)
added to Interpreter.Interpret(file) method, including:

Interpreter.Interpret(GCodeLines as collection)
Interpreter.Interpret(GCodeLines as array)

...where GCodeLines is a collection or array of single strings
consisting of lines of gcode.

This would avoid the thrashing disk accesses and pauses that happen
where lots of single gcode commands are sent one file at a time to the
interpreter.

Please and thank you!

sam marrocco | chief technical officer
ringside.cutters.flavor.picnic.moonlink

248 548 2500 w
248 910 3344 c

ringsidecreative.com

<http://ringsidecreative.com/>
Group: DynoMotion Message: 12451 From: Marrocco, Sam Date: 10/28/2015
Subject: Re: Feature wish for Interpreter in dotnet
On 10/28/2015 1:25 AM, TK tk@... [DynoMotion] wrote:
 

Hi Sam,

I think this would be a very difficult thing to add because of all the (unfortunate) dependencies on operating on a file.  Such as subroutine calls and returns, error line number reporting, rewinding on Halt, status callbacks, executing up to a certain line number or number of lines, etc. 

Why not write the the lines of GCode to a file?  I don't think the disk thrashing of the file is a significant issue when you consider everything else that occurs when invoking the Interpreter.



I do currently write the lines of gcode to a file. For example, a macro button you press (G01 F50 X.01). Pressing this several times in a row is very "stuttery" for lack of a better word. The "generate temp file, write temp file, Interpret(tempfile), delete temp file" cycle works fine at times, then stutters other times. Sometimes this may be because the Filesystem is doing something else for a moment, latency in the hard drive device, etc. It has always seemed a bit kludgy. This could perhaps be corrected with some type of caching mechanism to minimize the write/read/delete cycles but I haven't attempted that at this time.

I can understand where the rewinding on halt and status callbacks would be an issue. Not to compromise the usefulness of the original function too much, but perhaps instead of a true overloaded method (implying it has the same functionality), it could be a new method something along the lines of:

Interpreter.InterpretLines(Lines as collection) as ErrorBlock

where ErrorBlock is a structure/class of

.ErrorLineNumber
.ErrorMessage
.etc...

Obviously some functionality is lost, such as the aforementioned status callbacks and such.

I see an added benefit to being able to have the app provide the gcode to the interpreter in this manner: It opens up the possibility of adding custom inline macros to the gcode that are acted upon by the application. For example:

Currently a GCode file is saved and then loaded by Interpret and run.

With an InterpretLines() method, the GCode file can be "enhanced" by adding custom statements/functions that are only interpreted by the application and ignored by GCode. The application is given the opportunity to read the file itself, act upon any custom statements, filter them out and then pass the remaining true gcode lines to the Interpret(Lines) method. A simple example:

G90
G01 F5 X1
(MyApp DoCustomFunction1)
G01 F5 X-1
(MyApp DoCustomFunction2)

Of course, this relies on my reading of the file and sending line 1 and 2 to InterpretLine(), then acting internally upon the line beginning with MyApp, the sending the next gcode line to Interpret(), etc...but it does allow a certain amount of customization of the GCode file, not that all would want that as it means being careful with compatibility.

I leave it in your hands to determine if it has merit for a future version....thanks!

--

sam marrocco | chief technical officer
ringside.cutters.flavor.picnic.moonlink

248 548 2500 w
248 910 3344 c

ringsidecreative.com
Group: DynoMotion Message: 12454 From: TK Date: 10/28/2015
Subject: Re: Feature wish for Interpreter in dotnet
Hi Sam,

I think something else is going on.  On my 5+ year old 32-bit W7 computer I tested:

    AfxMessageBox("start");
    for (int i=0;i<20000;i++)
    {
        FILE *g = fopen("r:\\temp\\junk.txt","wt");
        fprintf(g,"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX");
        fclose(g);
        g = fopen("r:\\temp\\junk.txt","rt");
        fgets(s.GetBufferSetLength(100),99,g);
        s.ReleaseBuffer();
        fclose(g);
        remove("r:\\temp\\junk.txt");
    }
    AfxMessageBox("stop");

On average it only takes 800us to create/write/read/delete the file.   Using my RAM disk reduced it to 500us.

So compared to pushing a button with your finger and everything else involved with invoking the Interpreter I can't see how it would make a detectable difference.  My reluctance to add specific ways to invoke the Interpreter and handle all the special cases it introduces is the complexity it adds, the potential for bugs, the difficulty it adds to enhancing the Interpreter, and the extra documentation required.

I don't think your example would work because the custom functions  would be out of sync with the GCode.

But you are about the 10th person to ask for that functionality!

We might be able to figure out why your macro button is "stuttery" but I doubt it has to do with the file accesses.

Regards
TK


On 10/28/2015 6:39 AM, 'Marrocco, Sam' SMarrocco@... [DynoMotion] wrote:
 

On 10/28/2015 1:25 AM, TK tk@... [DynoMotion] wrote:
 

Hi Sam,

I think this would be a very difficult thing to add because of all the (unfortunate) dependencies on operating on a file.  Such as subroutine calls and returns, error line number reporting, rewinding on Halt, status callbacks, executing up to a certain line number or number of lines, etc. 

Why not write the the lines of GCode to a file?  I don't think the disk thrashing of the file is a significant issue when you consider everything else that occurs when invoking the Interpreter.



I do currently write the lines of gcode to a file. For example, a macro button you press (G01 F50 X.01). Pressing this several times in a row is very "stuttery" for lack of a better word. The "generate temp file, write temp file, Interpret(tempfile), delete temp file" cycle works fine at times, then stutters other times. Sometimes this may be because the Filesystem is doing something else for a moment, latency in the hard drive device, etc. It has always seemed a bit kludgy. This could perhaps be corrected with some type of caching mechanism to minimize the write/read/delete cycles but I haven't attempted that at this time.

I can understand where the rewinding on halt and status callbacks would be an issue. Not to compromise the usefulness of the original function too much, but perhaps instead of a true overloaded method (implying it has the same functionality), it could be a new method something along the lines of:

Interpreter.InterpretLines(Lines as collection) as ErrorBlock

where ErrorBlock is a structure/class of

.ErrorLineNumber
.ErrorMessage
.etc...

Obviously some functionality is lost, such as the aforementioned status callbacks and such.

I see an added benefit to being able to have the app provide the gcode to the interpreter in this manner: It opens up the possibility of adding custom inline macros to the gcode that are acted upon by the application. For example:

Currently a GCode file is saved and then loaded by Interpret and run.

With an InterpretLines() method, the GCode file can be "enhanced" by adding custom statements/functions that are only interpreted by the application and ignored by GCode. The application is given the opportunity to read the file itself, act upon any custom statements, filter them out and then pass the remaining true gcode lines to the Interpret(Lines) method. A simple example:

G90
G01 F5 X1
(MyApp DoCustomFunction1)
G01 F5 X-1
(MyApp DoCustomFunction2)

Of course, this relies on my reading of the file and sending line 1 and 2 to InterpretLine(), then acting internally upon the line beginning with MyApp, the sending the next gcode line to Interpret(), etc...but it does allow a certain amount of customization of the GCode file, not that all would want that as it means being careful with compatibility.

I leave it in your hands to determine if it has merit for a future version....thanks!

--

sam marrocco | chief technical officer
ringside.cutters.flavor.picnic.moonlink

248 548 2500 w
248 910 3344 c

ringsidecreative.com